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Abstract — This paper proposes a new departure pushback 
decision-support tool (DST) for airport ramp-tower controllers. 
It is based on NASA’s Spot and Runway Departure Advisor 
(SARD A) collaborative decision-making concept, except with the 
modification that the gate releases now are controlled by tactical 
pushback (or gate-hold) advisories instead of strategic pre- 
assignments of target pushback times to individual departure 
flights. The proposed ramp DST relies on data exchange with the 
airport traffic control tower (ATCT) to coordinate pushbacks 
with the ATCT’s flow -management intentions under current 
operational constraints, such as Traffic Management Initiative 
constraints. Airlines would benefit in reduced taxi delay and fuel 
burn. The concept was evaluated in a human-in-the-loop 
simulation experiment with current ramp-tower controllers at 
the Charlotte Douglas International Airport as participants. The 
results showed that the tool helped reduce taxi time by one 
minute per flight and overall departure flight fuel consumption 
by 10-12% without reducing runway throughput. Expect 
Departure Clearance Time (EDCT) conformance also was 
improved when advisories were provided. These benefits were 
attained without increasing the ramp-tower controllers’ 
workload. Additionally, the advisories reduced the ATCT 
controllers’ workload. 

I. Introduction 

A. Background 

Airport ramps , also called aprons or non-movement areas , 
are the areas outside taxiways and runways used for airplane 
parking, loading/unloading, refueling, and maintenance. In 
U.S. airports, Federal Aviation Administration (FAA) 
controllers are not responsible for traffic movements in non- 
movement areas [1]. To ensure safety and efficiency in ramp 
areas, many large hub airports in the United States have ramp 
towers operated by airlines, airports, or third-party companies. 
Controllers in the ramp towers oversee aircraft traffic in the 
ramp areas, including departure pushbacks from the gates. 
Since ramp towers are not a part of the FAA’s operations, their 
controllers may not be receiving the latest traffic and planning 
information from the FAA. Likewise, controllers at the FAA 
airport traffic control tower (ATCT or, simply, tower in this 
paper) may not be aware of activities in the ramp areas. 
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Currently, ramp-tower controllers, or ramp controllers , 
push departures off the gate on a first come, first served basis. 
However, pushing back departures and having their engines 
started too early may result in inefficient operations if the flight 
has a known delay. The proposed ramp controller decision- 
support tool (DST) will provide the ramp controllers pushback 
or gate-hold advisories for individual departures. The 
advisories are coordinated with ATCT operations by taking the 
ATCT’s operational constraints into account, such as taxiway 
congestion, runway-queue lengths, and Traffic Management 
Initiative (TMI) constraints (e.g., miles in trail, or MIT). This 
new ramp controller DST is a modification of NASA’s original 
Spot and Runway Departure Advisor (SARD A) concept. It was 
adapted for use by the ramp controllers at the Charlotte 
Douglas International Airport (CLT), and it is hereinafter 
referred to as SARD A- CLT to differentiate it from the two 
previous SARDA concept variants described later. 

All SARDA concepts meter departures so that a part of 
their taxi delay is shifted to the gate, where the aircraft can wait 
with its engines turned off. Note that this approach may not 
necessarily reduce the total departure delay (i.e., the delay 
between pushback-ready and takeoff) if the runway throughput 
level stays the same. However, the taxi delay (i.e., the delay 
between engine-start and takeoff) may be reduced by shifting 
the wait time to the gate. Thus, fuel savings are one of the 
expected benefits of the tool. Reduced fuel burn also should 
decrease the airport’s environmental footprint. In addition, 
departure metering is expected to lower the traffic level on the 
airport surface, and, thus, may help relieve the ramp and tower 
controllers’ workload. Lastly, coordinated pushbacks, reduced 
taxi time, and a less-congested airport surface may in concert 
allow more flights to conform to their assigned takeoff time, 
such as Expect Departure Clearance Time (EDCT), with higher 
precision, or, in general, for all departures to achieve better 
takeoff time predictability. The last benefit offers the FAA and 
airlines the potential to improve the precision of traffic-flow 
planning in the National Airspace System. 

B. Previous Works: SARDA-DFW and SARDA- CDM 

The SARDA concept was initially developed as a tower 
controller DST for the Dallas/Fort Worth International Airport 
(DFW) ATCT (SARDA-DFW) [2-4]. SARDA-DFW provides 



runway usage advisories to the Local controller and spot- 
release advisories to the Ground controller. (A spot is a point 
located between the ramp and the movement area.) The 
SARDA-DFW concept was demonstrated and evaluated in 
human-in-the-loop simulations with retired DFW tower 
controller participants in 2010 [2] and 2012 [3-4]. The results 
of the 2012 experiment showed that, for departures, the 
SARDA advisories reduced taxi delay by 60% and fuel burn by 
33% on average in heavy traffic scenarios [3]. The advisories 
also reduced the tower controllers’ workload levels [4]. 

Although the results appeared promising, managing the 
ramp traffic was outside of the focus of those studies. Thus, the 
ramp operations were not simulated realistically (e.g., airplanes 
were automatically pushed back at the ideal moment and were 
allowed to pass through other traffic). With more realistic 
uncertainties and ramp traffic movements, the benefits might 
be reduced. Put differently, to realize the maximum benefits, 
good coordination among the ATCT, the ramp, and airlines 
would be necessary. 

To address this gap, the SARDA Collaborative Decision 
Making concept (SARDA- CDM) was developed and published 
[5]. It requires data exchange between the ATCT and the ramp 
tower and assigns airlines a target pushback time and a target 
spot-release time window for each departure flight v hours 
ahead of time (the look-ahead period, jc, should be tailored for 
each airport). Each flight is expected to push back as close to 
the target time as possible, and arrive at the spot within the 
assigned time window. These pre-assignments add strategic 
planning components to the traffic flow control, whereas the 
SARDA-DFW ’s tower controller advisories manage the 
tactical aspect. 

Table I shows a comparison of the SARDA concept 
variants. SARDA-CLT is also listed for comparison and is 
explained in a later section. All three SARDA concepts use a 
common scheduler algorithm, the Spot Release Planner (SRP). 


TABLE I. Comparison of SARDA Concept Variants 
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C. Other Ramp-Related Studies 

As described in the next section, the present paper primarily 
focuses on the ramp operations, which often were overlooked 
in previous studies. However, implicitly, ramp operations have 
been included in past CDM and departure-management studies 
if their concept involved any form of pushback management. 

Some of the departure management concepts meter flights 
at the entrance point to the movement area rather than at the 


gates. Ramp controllers must use their discretion to decide 
when to push back each aircraft to comply with the metering 
requirements, such as Target Movement Area Entry Time or 
the count of departures that are allowed to enter the movement 
area within a specific time window. Thus, this is an indirect 
way to manage pushback times. The Saab Sensis’s Ground 
Management Program (GMP), currently used at John F. 
Kennedy International Airport (JFK) [6-7]; the FAA’s 
Collaborative Departure Queue Management (CDQM) 
concept, tested at Memphis International Airport [8]; the 
FAA’s Collaborative Departure Scheduling (CDS) concept [9]; 
and the FAA’s latest airport surface CDM concept [10] all 
manage pushbacks in this manner. 

Another type of departure management concept meters the 
departure flights at their gates. This approach is effective if the 
goal is to minimize the flights’ engine-on time. The original 
departure CDM tool for JFK, developed by PASSUR 
Aerospace [11]; Europe’s Airport CDM (A-CDM), being used 
at several European airports [12] ; and Massachusetts Institute 
of Technology’s Pushback Rate Control, tested at Boston 
Logan International Airport (BOS) [13-14], directly meter 
pushbacks. In JFK’s CDM tool and the A-CDM, pilots are 
assigned a specific target pushback time, which is the time they 
are supposed to call the ramp controller. In the Pushback Rate 
Control, the current target release rate is provided to the gate 
controller located in the ATCT without specifying which 
aircraft is to be pushed. 

D. SARDA-CLT for New Ramp Controller DST 

This section describes the SARDA-CLT concept, the 
subject of the present study. With collaboration from American 
Airlines (formerly, US Airways) at CLT, SARDA-CLT was 
developed to adapt to their use in the ramp tower. 

Three factors influenced the formation of SARDA-CLT 
from SARD A-CDM. First, SARDA-CLT was developed as a 
DST for the ramp controllers, and, therefore, the SARDA- 
CDM’s tower controller advisory capabilities for the Ground 
and Local controllers were disabled (see Table I, the last two 
columns). The tool still was assumed to receive sufficient data 
via the FAA’s data network to ensure coordinated pushbacks 
with the ATCT. An interesting question that arises here is how 
much benefit a ramp-tower DST alone can achieve by 
indirectly controlling the movement-area traffic only through 
pushback metering. If a reasonable level of benefit is 
achievable without a tower implementation, the ramp -only 
implementation could be an attractive alternative. To answer 
the question, later in this paper, the results of the present 
study’s human-in-the-loop simulation are compared with the 
results of a previous fast-time numerical simulation study. 

Second, CLT is one of American Airlines’ major hub 
airports, where over 85% of the traffic is American Airlines 
flights. Since there is little concern regarding equitability and 
adverse gaming behaviors from airlines (e.g., requesting 
pushback even before the flight is ready just to secure a slot), 
target pushback time and spot-release time window constraints 
on the airlines were removed. While removal of the pre- 
conditioning of pushback orders may result in failure to 
achieve the theoretical best benefit level for the given set of 



scheduled departures, dropping these constraints makes it 
easier for American Airlines to adapt to SARDA-CLT in the 
future. Hence, SARDA-CDM’s strategic components (the first 
and third columns in Table I) were replaced with tactical 
pushback advisories for ramp controllers (the second column). 
In addition, SARDA-CLT complies with American Airlines’ 
current policy that, when any OA flight requests pushback, it 
should be approved immediately, barring any safety issues. 

Third, American Airlines requested that the tool provide a 
pushback or gate-hold advisory at the moment the pilot calls to 
request a pushback, without the controllers’ need to input to the 
SARD A scheduler which flight just called each time. This 
addresses controllers’ workload issues when multiple aircraft 
call. This request, however, forced the pushback advisories to 
act like a simple pushback rate control, i.e., departures that had 
similar pushback times, the same fix, etc., showed the same 
pushback advisory, and all advisories were updated each time a 
new pushback was issued. Still, unlike in a pure rate-control 
scheme, flights with MIT or EDCT constraints could be 
advised to hold a little longer than others to wait for the next 
slot. Also, if a slot suddenly opened up, some gate-hold time 
advisories might jump down to a shorter hold time to take 
advantage of it. 

The SARDA-CLT ’s scheduler, the Spot Release Planner 
(SRP), works as follows [15-16]. The scheduler takes as input 
the current snapshot of the airport, aircraft- specific parameters, 
separation constraints, scheduled pushback times, and 
scheduled arrival times for the aircraft in the next 15 minutes. 
Then, the departures are divided into five groups: (a) 
scheduled_out (aircraft whose scheduled pushback time is 
within 15 minutes, but pilot has not called for pushback), (b) 
pushbackjiold (pilot has called for pushback, but controller 
has put the aircraft on hold), (c) pushback_approved (controller 
has approved its pushback, but aircraft has no surveillance- 
radar hits, yet), (d) taxi_out (aircraft with taxi approval and 
under surveillance), and (e) unknown. The arrivals are divided 
into four groups: (a) scheduled_on (aircraft scheduled within 
the 15 -minute planning window, but not visible on radar), (b) 
airborne (on final with surveillance), (c) taxi_in (on airport 
surface and has not reached gate), and (d) unknown. 

Next, the taxi estimator module calculates the relevant 
runway, unimpeded queue-entry time, and runway-crossing 
queue entry time for each aircraft. The scheduler also computes 
the required separation between each pair of departing aircraft. 
This consists of separation in either time or distance, and takes 
into account the most restrictive separation as the required 
value. The separation criteria consider the wake vortex 
separation, separation between aircraft going to the same fix, 
MIT separations, converging-runway separation, Arrival 
Departure Window for nonintersecting converging-runway 
separation, takeoff-landing mixed-use runway separation, 
crossing-takeoff separation, crossing-landing separation, and 
parallel runway separation. The nine previously mentioned 
groups of aircraft, along with the separation requirements, are 
passed to a runway scheduler that calculates the best runway 
usage schedule for arrivals and departures. 

The runway scheduling problem can be solved for multiple 
objectives, including throughput (runway usage time for the 


last aircraft) and system delay (total delay for all aircraft). The 
runway scheduler for the simulation was implemented as a 
Mixed Integer Linear Program (MILP) and solved for optimal 
system delay using the commercial solver, Gurobi [17]. The 
scheduled_out departures were not considered in the MILP 
planner. Once the MILP provides an optimal runway sequence, 
scheduled_out aircraft are assigned to empty slots, provided the 
assignment does not cause a change in the time for the other 
aircraft following the inserted aircraft. 

After the runway scheduler optimizes the takeoff time for 
each departure, the pushback estimator module calculates the 
required pushback time for each aircraft. Departures that will 
cause a gate conflict with incoming aircraft are given a higher 
priority in pushback slot. 

The scheduler receives an updated airport condition 
snapshot every 10 seconds, which is then used to recalculate 
the schedule. A two-minute freeze horizon is implemented to 
increase the stability of the advisories. That is, for the flights 
held at the gate with an advised gate-hold time of two minutes 
or shorter, the hold time can no longer increase but only 
decrease. 

Furthermore, the scheduler also provides a suggestion for 
possible use of a Mike -Charlie (MC) taxi way bypass route for 
arrivals (the thick solid magenta lines in Fig. 1). Note that the 
MC-bypass advisory component is unique to the CLT ramp 
application. This bypass sends arrivals back to the ATCT 
control from ramp; thus, it requires additional coordination 
with the ATCT. The purpose of the advisory is to assist 
resolving the major bottleneck of ramp traffic around the 
single-lane area, a narrow corridor between Spots 8 and 12, 
which allows only a single direction of traffic at a time (the 
thin, dotted blue line in Fig. 1). A set of fuzzy control rules is 
used to select which arrival to suggest a MC bypass. 



Figure 1. CLT airport ramp. (The MC taxi way bypass is shown in thick solid 
magenta lines. Yellow circles with a number are spots. The dotted, thin blue 
line between Spots 8 and 12 depicts the single lane.) 


II. Methods 


A. Simulation Facility 

The ramp-tower simulation study was conducted at the 
NASA Ames FutureFlight Central (FFC) facility. The two- 
story FFC facility hosted tower controller and pseudo-pilot 


stations on the first floor, and ramp controllers on the second 
floor (Fig. 2), where a 360-degree out-the- window (OTW) 
visual system was provided by the MaxSim system. Voice 
radio communication systems were supplied by SimPhonics. 



Figure 2. Ramp tower simulator at NASA FutureFlight Central. 


Upstairs, the space was set up to support a Ramp Manager 
(RM) station and four ramp sector controller stations: from left 
to right, RM, North, East, South, and West ramp controllers 
(Fig. 2). The four ramp controller participants used a surface 
radar display, Ramp Traffic Console (see the next section), and 
the OTW visual to survey and control traffic. The researcher 
station, shown in the foreground in Fig. 2, was used to initiate 
system startup, monitoring, and data recording. 

The space on the first floor of the FFC was configured to 
support three tower controllers (Local East, Local Center, and 
Ground) and nine pseudo pilots. Six of the pilots controlled 
aircraft in the ramp area, while the remaining three pilots 
provided control in the movement area. The airport traffic was 
simulated using Surface Decision Support System (SDSS) 
software developed by Mosaic ATM, Inc., and Airspace 
Traffic Generator (ATG) software developed in-house at 
NASA, each of which also provided user interface for the 
tower controllers (SDSS) and the pseudo pilots (ATG), 
respectively. 

B. Ramp Traffic Console 

The paper strip system currently used at the CLT ramp 
tower is not compatible with the SARDA-CLT concept, as the 
concept requires the capability to show real-time updates of the 
advisories to the controller. Thus, the SARDA team developed 
a new electronic display, the Ramp Traffic Console (RTC). 
This Java-based user interface software displays virtual strips 
on a 27 -inch touchscreen monitor (Fig. 3). Each sector 
controller was provided with one RTC display. 



Figure 3. Ramp controller interacting with the RTC. 



Figure 4. RTC screenshot. 


On the RTC, rectangular virtual strips are shown on a map 
graphic. See Fig. 4 for an example screenshot. The virtual 
strips are movable and rotatable, just like the physical paper 
strips. Unlike the paper strip system, the RTC map can be 
zoomed in and out by using a two-finger pinch action and can 
be dragged around to show different viewpoints of the airport. 
The RTC also incorporates aircraft radar position readings on 
the same map view, eliminating the need to frequently 
crosscheck the separate radar display. On the RTC, radar- 
acquired target positions are depicted as a filled airplane icon, 
clearly distinguished from the virtual strips. 

SARDA-CLT ’s tactical pushback advisories are displayed 
next to the departure strip in cyan color. For instance, if it says 
“7 min” (as shown at gate CIO in Fig. 4), a gate hold for seven 
minutes would be advised if the pilot requests a pushback now 
(note that the pilot has not requested it yet). For a flight 
currently being held, the RTC displays a countdown timer, 
which reaches “0:00” at the advised pushback time to assist the 
controller with timing the pushback approval. After passing the 
advised pushback time, a count-up timer is shown along with 
the pulsing text “Push” (shown at gate Cl 8 in Fig. 4) to warn 
the controller. Flights currently being held at the gate also are 
marked with red outlines for additional saliency. 

Furthermore, the controller’s actions are used to inform the 
scheduler of the controller’s traffic-management actions and 
intentions. For example, when the controller verbally issues a 
pushback approval to a pilot, the controller slides the flight’s 
virtual strip away from the gate, which puts the virtual strip in a 
pushed-back state (in Fig. 4, marked with a yellow circle icon, 
shown next to the aircraft icon near gate Cl 5) and, at the same 
time, signals to the scheduler that the pilot now has been 
instructed to push back. On the RTC, the ramp controller also 
can indicate a gate hold, spot change, hold in a hardstand, or 
MC-bypass request. The more information the controller inputs 
into the RTC, the more accurate the scheduler’s prediction will 
become. 





C. Traffic Scenarios 

Two one-hour-long scenarios, labeled Scenario 1 and 
Scenario 2, were created to mimic the traffic at CLT on the 
date of May 16, 2013. That date had clear weather, a South- 
flow configuration, and a distinct arrival and departure traffic 
profile with minimal overlapping. In South flow, departures 
used runways 1 8L and 1 8C, and arrivals used runways 1 8R and 
23. The scenarios included a departure push followed by an 
arrival push, and were compressed slightly in time to fit all 
traffic into the hour-long test duration and create some overlap 
in the departure and arrival push. Fig. 5 shows the traffic 
demand for each scenario. Both scenarios were designed to 
model current-day heavy operations at CLT. Scenario 1 had 96 
departures and 80 arrivals, whereas Scenario 2 had 84 
departures and 72 arrivals. Fig. 5 shows that Scenario 1 had 
greater overlap between departure and arrival push. There was 
no planned gate-conflict situation in either scenario; yet, a 
delayed pushback still could have caused a new gate conflict 
with an arrival. General aviation, military, and cargo aircraft 
were not included in the scenario, since their impacts on the 
commercial airline operations are negligible at CLT. 
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D. Experiment Design 

The three- week-long experiment took place in September 
and October 2014. In each week, 16 data-collection runs were 
conducted, resulting in 48 runs total. Each week, a different 
pair of current CLT ramp controllers participated in the study. 
They alternated between East and South sectors in each run. 
The remaining ramp sectors (North and West) and the three 
tower positions (two Locals and one Ground) were staffed by 
confederate controller participants, and all of them stayed at the 
same position throughout the three weeks, except that the 
Ground controller was substituted by another confederate 
controller during Week 2. The alternating East and South ramp 
sector controllers created six Controller Seat assignments (i.e., 
two assignments per week for three weeks). The Controller 
Seats are important for even the confederate controllers, since 
performance of the same controller at the same position could 
be affected differently by who controls the East and South 
sector traffic. The RM position was staffed by a NASA 
researcher. 

The SARDA-CLT advisories were presented in eight runs 
per week {Advisory runs), and the remaining eight runs were 
Baseline runs, where the controllers were not shown any 
advisories and were asked to operate traffic as they would 
normally. The RTC was used in both Advisory and Baseline 
runs. In Baseline runs only, the RTC presented a count of the 
active departures per each runway (the active departures are 
those that had initiated pushback but had not yet been 
airborne), and the ramp controllers were asked to meter the 
departures by targeting these counts to be 15 or smaller, to 
mimic the departure metering scheme currently practiced at the 
CLT ramp. These counts were not shown in Advisory runs, as 
the pushback advisories were expected to take care of the 
metering requirements automatically. 

If a flight had an assigned EDCT, the Local controllers 
were asked to have it depart within a ±1 -minute window or, if 
that was not possible, as close to the EDCT as possible. A 
tighter EDCT window than the one used in the current-day 
operations (±5 -minute window) was applied in the simulation 
to improve takeoff time conformance and make the task more 
challenging to the controllers. 


Figure 5. Aircraft counts for the two scenarios. 

Scenarios were generated such that departure traffic began 
at the gates upon activation in the simulation, and arrival 
aircraft appeared about 10 nautical miles from the airport. 
Scenario data included the scheduled gate-out time (the time 
the scheduler used), as well as the actual flight-ready time, 
which is the time the pseudo-pilot is prompted to call the ramp 
controller for pushback. The scenario data files enabled us to 
model gate-out uncertainty in the simulation while ensuring 
repeatability across different runs. Similarly, the scenario data 
also included entries for aircraft- specific variations in pushback 
time, engine spool-up time, and taxiing speeds. TMI 
information also was stored in the scenario data. In this 
simulation, two types of TMIs were implemented: 1) MIT 
restrictions of 15 miles over the MERIL departure fix, and 2) 
EDCT for five aircraft in each scenario. 


The MC-bypass operation required the RM to coordinate 
with the Ground controller via radio. In Advisory runs, a MC 
advisory computed by the scheduler was displayed next to the 
corresponding arrival aircraft symbol on the RTCs. (An 
example of a MC bypass going to Spot 11, “MC:S11,” is 
shown in Fig. 4, near the upper left corner.) Unless the East- 
sector controller canceled it via his/her RTC, the RM contacted 
the Ground controller and requested an approval to use the 
taxi ways. Once it was approved, the RM indicated the 
confirmed state of the MC-bypass request via his/her RTC. 
This informed the East-sector controller that he/she now could 
send the arrival to the MC taxi ways. In both Advisory and 
Baseline runs, any sector controller could initiate a MC-bypass 
request via his/her RTC; however, normally the East-sector 
controller handled MC-bypass operations. 

Traffic performance data and scheduler performance data 
were recorded with time stamps. For subjective data, real-time 
workload ratings and questionnaire responses were collected. 




For the real-time workload ratings, the ramp and tower 
controllers reported their workload ratings using quick hand 
signs at five-minute intervals when a beep sounded, and 
researchers recorded the ratings. The ratings used a scale of one 
to seven, where 1 meant very low and 7 very high. The post- 
run questionnaire collected the ramp controllers’ workload 
ratings, including Mental Demand (thinking, deciding, 
calculating, remembering, searching, etc.); Time Pressure; 
Frustration (stress, annoyance, or irritation); Communication 
(exchanging information, discussion, negotiation, etc.); and 
Coordination (flow coordination, hardstand use, MC bypass, 
etc.). The first three ratings are a subset of the NASA Task 
Load Index (TLX) [18]. The last two ratings, Communication 
and Coordination, were added to assess the teamwork-related 
workload levels [19]. Additionally, the post-run questionnaire 
gathered responses related to usability and situation awareness 
from the ramp controllers. A post-study questionnaire also was 
administered at the end of each week to gather additional 
responses and feedback from the ramp controllers. 

Independent variables were Advisory (Advisory vs. 
Baseline runs), Scenario (1 vs. 2), and Controller Seats (1 
through 6). The design was 2x2x6, with two repetitions for 
each combination. Note that the CLT ramp controller 
participants were nested in each week. To reduce any learning 
and/or fatigue bias, the run order in each week was 
counterbalanced within and between the two Controller Seats 
corresponding to the week. 

On the first day of each week, a classroom training session 
was provided to the two new CLT ramp controller participants, 
followed by hands-on training in the ramp -tower simulator. 
Once the new ramp controller participants were accustomed to 
the simulation setup, including the RTC and the traffic 
management tasks in each of the Advisory and Baseline runs, 
five to seven training runs were conducted with all of the 
remaining confederate-controller and pseudo-pilot participants. 
The training lasted until the researchers judged the participants 
to be ready. Then, the data-collection runs were started in the 
late morning of the second day and ended in the middle of the 
fifth day. 

E. Participants 

All six CLT ramp controllers were current at the time of the 
study and had been working in the CLT ramp tower for four to 
25 years (Mean = 9.4 years, Standard Deviation = 7.9 years). 
One of the two confederate ramp controllers was a current 
Dallas/Ft. Worth International Airport ramp controller for the 
last 18 years, and the other was a retired Los Angeles 
International Airport tower controller with 20 years of 
experience in that tower and 25 years of experience in ATCTs 
overall. The two confederate tower controllers who staffed the 
two Local controller positions were retired CLT tower 
controllers with 30 and 20 years of experience in that tower. 
The two tower controllers who staffed the Ground position 
were both retired San Francisco International Airport (SFO) 
tower controllers with 20 and 16 years of experience in that 
tower, or 22 and 26 years of total experience, respectively, in 
various ATCTs. All the retired confederate controller 
participants had retired within the last four years, except one of 
the SFO tower controllers, who retired ten years ago. All the 


pseudo-pilot participants were either general aviation pilots or 
former FAA controllers recruited from the local area. 

III. Results 
A. Traffic Performance 

1 ) Departure Runway Performance: The number of 
aircraft that took off in a given time period was investigated to 
assess the departure runway performance, and no difference 
was found between Advisory and Baseline runs. This implies 
that there was no loss in runway usage caused by the SARDA’s 
departure metering. 

2) Departure Taxi Delays : Taxi delay is defined as the 
difference between the observed travel time and the unimpeded 
travel time for the same route. A taxi speed of 17 knots was 
used for calculating unimpeded travel times. For departure 
aircraft, taxi delay represents the total delay in the ramp, 
taxiways, and runway queues, but not at the gate. The Fig. 6 
box plots show distributions of taxi delays. In Advisory runs, 
the variation in taxi delay was less when compared to Baseline 
runs, and there was a reduction in mean taxi delay in Advisory 
runs over all cases. Over the three weeks, the average taxi 
delay in Advisory runs was 346.8 seconds per aircraft (standard 
error, or SE = 3.8), whereas in Baseline runs, it was 403.2 
seconds (SE = 4.5). This accounted for an average reduction in 
taxi delay of one minute per aircraft. 


Week 1 Week 2 Week 3 



Baseline Advisory Baseline Advisory Baseline Advisory 


Figure 6. Departure taxi delay. (Horizontal bars indicate median, 25th, and 
75th percentile; vertical whiskers show 1.5 interquartile range, or IQR; 
triangles show the mean.) 

3) Departure Gate Delays: The gate delay is defined as the 
difference between the flight-ready time (the time the pseudo 
pilot was prompted to call the ramp controller) and the actual 
start of movement. Fig. 7 shows their distributions. On 
average, the ramp controllers held the aircraft at the gate 90 
seconds longer in Advisory runs as compared to Baseline runs. 
Moreover, it is evident from Fig. 7 that the controllers held 
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Figure 7. Gate delay for departures. (Horizontal bars show median, 25th, and 
75th percentile; vertical whiskers show 1.5 IQR; triangles show the mean.) 

some aircraft at the gate for a long time in Baseline runs as 
well, and the longest gate-hold times in Baseline and Advisory 
runs were roughly comparable. 

4) Departure Queue Size: Fig. 8 shows the average count 
of departures in the movement area by simulation time. The 
number of departure aircraft (to both runways 18L and 18C) 
was lower in Advisory runs than in Baseline runs. The lower 
number of departures in the movement area was one of the 
expected benefits of SARD A metering. 



Figure 8. Number of departures in the movement area as a function of 
simulation time. 


5) Total Delay: The total delay of departure is the overall 
delay experienced by the aircraft at the gate, the ramp, 
taxi ways, and the runway queue. This delay is defined as the 


observed takeoff time minus the unimpeded takeoff time given 
the scheduled pushback time. In Baseline runs, the mean total 
delay was 500.2 seconds (SE = 5.8), and Advisory runs had a 
mean of 529.0 seconds (SE = 6.6). The total delay is about 30 
seconds longer in Advisory runs than in Baseline runs, 
suggesting something did not work as intended. 

The above results were derived taking all departure aircraft 
in the scenario into account, including the departures to the 
MERIL fix with the 15 MIT restrictions. In both scenarios, a 
few other-airlines (OA) flights were routed through MERIL. 
Since it was the American Airlines policy not to include the 
OA flights in the departure metering, these OA flights to 
MERIL were released as soon as they called. This interfered 
with the planning in the other sectors’ MERIL departures and 
increased the total delay. If all the aircraft with MIT restrictions 
were removed from the calculations, Baseline runs resulted in 
an average total departure delay of 440.8 seconds (SE = 5.1), 
whereas the average in Advisory runs was 446.8 seconds (SE = 
5.2). The results now appear comparable to each other. 

6) Fuel Burn and Emissions: The amounts of fuel 
consumption and gas emissions were estimated by using the 
engine emission certification data from the International Civil 
Aviation Organization (ICAO) [20]. It was assumed that two 
engines were running at a standard thrust setting of 7% during 
the taxi phase of a flight, whereas they were turned off when 
the aircraft was being held at the gate. Table II lists the average 
fuel use and emissions per run and their reductions observed in 
Advisory runs. The reduction percentage was calculated 
relative to the Baseline average. 


TABLE II. Fuel Burn and Emissions for Departures (kg/run) 


Scenario 

Advisory 

Fuel 

HC 

CO 

NOx 


Baseline 

11124.30 

36.21 

449.11 

80.43 

1 

Advisory 

9789.58 

31.89 

395.52 

70.80 

Reduction 

(%> 

1334.72 

(12.0%) 

4.32 
(1 1 .9%) 

53.59 

(11.9%) 

9.63 

(12.0%) 


Baseline 

10113.50 

31.50 

399.95 

75.05 

2 

Advisory 

9066.72 

28.54 

360.56 

67.08 


Reduction 

(%) 

1046.78 

(10.4%) 

2.96 

(9.4%) 

39.39 

(9.9%) 

7.97 

(10.6%) 


7) EDCT Conformance: Each scenario included five 
departures that had an assigned EDCT. To examine the 
conformance, the observed takeoff time (the time the aircraft 
started takeoff roll) was compared to the assigned EDCT. Fig. 
9 shows the distribution of EDCT deviations aggregated over 
all Baseline runs (top) and all Advisory runs (bottom). The 
histograms show that Advisory runs resulted in a tighter 
distribution around the zero EDCT deviation than Baseline 
runs. The controllers were able to adhere to the EDCT 
constraints more precisely in Advisory runs. In Baseline runs, a 
few aircraft were delayed by up to five minutes. (Note that the 
Local controllers were asked to release EDCT departures 
within a ±1 -minute window in this simulation, rather than the 
±5 -minute window used in the real operations.) In both 
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Figure 9. Histogram of take-off time deviation from EDCT in Baseline runs 
(top) and Advisory runs (bottom). 

Baseline and Advisory runs, the controllers released some 
flights two minutes prior to the EDCT, though they did so more 
frequently in Baseline runs. 

B. Subjective Data Analysis Results 

The real-time workload ratings and numerical responses to 
the post-run questionnaire were subjected to linear mixed- 
models (LMMs) repeated-measures analysis [21]. Human 
participants’ subjective ratings may be influenced by additional 
factors. To account for these influences in the model fitting, 
two new effects were generated. These are listed in Table III. 


TABLE III. New Effects for Subjective-Data Analysis 


New Effect 

Descriptions 

Run Block 
(1-4) 

This effect represents the chronological order of the 
runs in each week. The effect may capture 
participants’ learning or fatigue trends, if any. The 
first four runs in each week were labeled 1 , the 
second four runs were 2, the third four runs were 3, 
and the last four runs were 4. 

Phase 

(1-4) 

Phase effect was relevant only to the real-time 
workload ratings. The effect mainly accounts for the 
influence from traffic volume changes within a single 
run. The ratings recorded in the first 15 minutes in a 
run were labeled 1 , the second 1 5 minutes were 2, 
the third 15 minutes were 3, and the last 15 minutes 
were 4. 


The data from the CLT ramp controllers, the confederate 
ramp controllers, and the tower controllers were analyzed 
separately, since their models were slightly different. Table IV 
lists the main effects included in the three models. In addition, 
two-way interaction effects that involved Advisory effect (e.g., 
Advisory x Scenario, Advisory x Sector) also were included in 
each model to assess the advisories’ secondary effects on the 
other effects. 


Main Effects Common in the Three Models 

• Advisory (Advisory vs. Baseline) 

• Scenario (1 vs. 2) 

• Run Block (1-4) 

• Phase (1 -4) - real-time workload rating models only 

Additional Main Effects 

CLT Ramp Confederate Ramp Tower Controllers’ 

Controllers’ Model Controllers’ Model Model 

• Sector (East vs. • Seat (1-6) • Seat (1-6) 

• Participant (7-8) • Participant (9-12) 

• Participant (1-6) 

The statistical software used was R [22] and its lme4 [23] 
and ImerTest [24] packages. Participant effect was treated as a 
random effect, and all other effects were treated as fixed 
effects. A likelihood-ratio test was performed to assess whether 
the Advisory x Participant term needed to be included in the 
model or not. Finally, using the derived model, statistical - 
significance levels for the fixed effects were calculated [24]. 

1) Real-Time Workload Ratings: The results found no 
statistically significant Advisory effect in the ramp controllers’ 
workload ratings. However, the LMM regression coefficient 
indicated that the CLT ramp controllers’ ratings were reduced 
by 0.17 (SE = 0.06, p = 0.008) in Advisory runs when they 
were in the South-sector position rather than in the East-sector 
position. Fig. 10 (left) plots the means to visualize the effect. 

The tower controllers’ ratings showed a statistically 
significant Advisory effect. In the seven-point scale, the tower 
controllers’ ratings were reduced by 0.23 (SE = 0.10, p = 
0.021) when advisories were provided in the ramp. 

2) Post-Run Workload Ratings: No statistically significant 
Advisory effect was found in the CLT ramp controllers’ 
Mental Demand, Time Pressure, Communication, and 
Coordination ratings; however, results showed that the CLT 
ramp controllers’ Frustration rating (stress, annoyance, or 
irritation) was reduced by 0.58 (SE = 0.30, p = 0.054), on a 10- 
point scale, when they were in the South sector rather than in 
the East sector in Advisory runs. In other words, when they 
were in the East sector, the advisories did not reduce the CLT 
ramp controllers’ frustration as much as when they were in the 
South sector. Fig. 10 (right) plots the means. The result is 
similar to the finding in the real-time workload ratings. 



East South East South 

Sector Sector 


Figure 10. Means of CLT ramp controllers’ real-time workload ratings (left) 
and post-run Frustration ratings (right). 






3) Post-Run Usability Responses: Statistically significant 
Run-Block effects were observed in some of the responses, 
suggesting that the controllers were learning over the course of 
the week. For instance, the CLT ramp controllers felt that the 
gate-hold time advisories appeared in a reasonable range (i.e., 
the time was not abnormally long) more frequently toward the 
end of each week. On a scale of one to seven (1 being always, 
7 never), the LMM analysis showed that the scores were 
reduced by 0.68 and 0.70 in Run Blocks 3 and 4, respectively, 
compared to those in Run Block 1 (SE = 0.33, 0.27; p = 0.045, 
0.014, respectively). Fig. 11 (left) plots the means of the scores. 

Toward the end of each week, the CLT ramp controllers 
also felt the MC advisories were stable more frequently (score 
differences compared to Run Block 1 = -0.77, -0.51, -0.60; SE 
= 0.22, 0.26, 0.22; p = 0.002, 0.058, 0.009, in Run Blocks 2, 3, 
and 4, respectively). Fig. 11 (right) shows the means. Note that 
the advisory algorithms were not changed in the course of the 
experiment. The results imply that some learning curves may 
be expected when the tool is brought to the field. 



Figure 11. Means and standard errors of CLT ramp controllers’ responses on 
how often the gate-hold advisories were perceived in a reasonable range (left) 
and how often the MC -bypass advisories were stable enough to use (right). 

IV. Discussion 

The results showed that the SARDA-CLT gate-hold 
advisories did not impact the runway throughput or the total 
delay (when all MERIL departures were excluded). The taxi 
delay was, on the other hand, reduced by one minute per flight 
when the advisories were provided. This means that the tool 
successfully shifted a portion of the taxi delay to the gate, 
where aircraft could wait with their engines turned off and save 
fuel. Indeed the increased gate-hold time contributed to a 10- 
12% fuel burn reduction for overall departure flights per run. 

The above fuel savings were achieved by using only the 
ramp tool (SARDA-CLT), rather than a full, airport-wide 
SARDA-CDM tool. Fast-time simulations of SARDA-CDM 
operation previously conducted estimated the achievable 
departure fuel savings to be 23-30% of the current-day fuel 
consumption levels [25]. Therefore, SARDA-CLT alone 
already achieved roughly 30-50% of the estimated fuel-saving 
benefit of SARDA-CDM without implementing the tower- 
controller advisories. 

The results also demonstrated that the MERIL OA flights, 
which were not subject to departure metering and were allowed 
to push back right away, could cause additional delays for 
American Airlines’ MERIL flights by assuming their takeoff 


slots. Therefore, it is recommended that OA flights be included 
in the metering if they have a TMI constraint. 

The advisories reduced the runway queue lengths, as 
expected. The results also showed the tower controllers’ self- 
reported workload was reduced, perhaps because of the 
presence of fewer departures in the movement area along with 
shorter runway queues. These results are consistent with the 
findings in the SARDA-DFW 2012 study [4]. The shorter 
queue lengths also can account for the improved EDCT 
conformance demonstrated in the current study. 

The study found no significant Advisory effect to the ramp 
controllers’ self-reported workload ratings. Thus, the tool’s 
benefits were achieved at least without negatively impacting 
the ramp controllers’ workload. The CLT controllers’ real-time 
workload ratings and the Frustration ratings were lowered by 
the advisories only in the South sector, not in the East sector. 
The major difference between the East and South sectors was 
that the East-sector controller handled the MC-bypass 
operations. The results imply that the pushback advisories 
successfully reduced the South controller’s workload and 
frustration, whereas the MC-bypass advisories increased those 
for the East-sector controller, canceling out the benefit of the 
pushback advisories. In Advisory runs, when the RTC was 
showing a provisional MC request, there were three possible 
cases: 1) the East controller requested it; 2) the SARDA’s 
scheduler suggested the MC bypass, and the East controller 
liked it (thus, left it as is); or 3) SARDA’s scheduler suggested 
the MC bypass, but the East controller had not had a chance to 
look at it due to high workload. Because of the ambiguity, the 
RM had to ask the East-sector controller about his/her intention 
each time before requesting permission from the Ground 
controller to use the MC taxi ways. This additional coordination 
may have burdened the East-sector controller in Advisory runs. 
In Baseline runs, all MC-bypass requests sent to the RM had 
been initiated by the East-sector controller; thus, there was no 
ambiguity. The method used to communicate and coordinate 
the MC bypass requires improvement in the future — which 
could be as simple as a different color used on the RTC 
between the controller-initiated versus advisory-initiated MC- 
bypass requests. 

V. Conclusion 

This paper presented a new ramp controller DST (SARDA- 
CLT) that utilized tactical pushback advisories for the ramp 
controllers. The tool did not provide the tower-controller 
advisories, but ensured coordinated pushbacks through data 
exchange with the ATCT. A human-in-the-loop simulation 
experiment demonstrated that the SARDA-CLT advisories 
reduced the departure taxi delay by one minute per flight and 
reduced fuel consumption in departure flights by 10-12%. The 
tool successfully reduced the runway queue length, which 
likely also improved EDCT conformance and reduced the 
tower controllers’ self-reported workload. The tool’s benefits 
were achieved without negatively impacting the ramp 
controllers’ self-reported workload. There were some 
indications that the tool’s pushback advisories reduced the 
ramp controllers’ workload, but that reduction may have been 
canceled out by the MC-bypass advisories’ high workload and 
frustration in the East sector. Minor changes to the RTC may 





mitigate these issues in the MC -bypass operations. The results 
also indicate it would be beneficial to change the current policy 
for handling the OA flights and include the OA flights with 
MIT constraints in the departure metering. Lastly, the results 
demonstrated that the ramp DST alone already could achieve 
30-50% of the fuel savings anticipated by an airport-wide full 
SARDA-CDM. 
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